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ABSTRACT 

A general definition of Mission Planning is first 
given, covering the full scope of an end-to-end 
mission planning system. Noting the mission-specific 
nature of most mission planning systems, a 
classification of autonomous spacecraft missions is 
made into Observatory, Survey, multi-instrument 
science and Telecommunications missions. The 
mission planning approach for one mission in each 
category is examined critically, the missions chosen 
being ISO (Infrared Space Observatory), ERS-1 
(European Remote Sensing Satellite) and Eureca 
(European Retrievable Carrier). The paper gives a 
summary of lessons learned from these missions, 
suggesting improvements in areas such as 

requirements analysis, testing, user interfacing, rules 
and constraints handling. 

The pap er will also examine commonalities in 
functions, which could constitute a basis for 
identification of generic mission planning support 
tools. 

L DEFINITION AND SCOPE OF MISSION 
PLANNING 

The term ’'mission planning" is used in this paper to 
refer to any system which plans the operations of a 
space system or any of its component parts. A 
Mission Planning system may plan platform 
operations, payload operations, on-board data 
handling (recorder or memory). It may also plan 
ground operations associated with the foregoing 
(ground station activities, payload data processing, 
product dissemination). 


The inputs to a planning system from the payload 
users can be either of the following: 

- requests for particular data, products or 
measurements 

- specification of specific payload operations, which 
may vary from high-level specification of operations 
required to binary command data at the lowest level 

The main outputs will be the final operations plan , 
which is passed to the commanding system at the 
control centre for translation into uplinkable form and 
execution. An appropriate set of mission rules and 
constraints governs the derivation of the operations 
plan from the user inputs. 

IL CLASSIFICATION OF MISSIONS 

Four mission types are identified: Survey, 

Observatory, Multi-Instrument PI Missions and 
Telecommunications . 

Observatory Missions : the spacecraft has one main 

instrument (usually a telescope, although there may 
be several focal plane instruments). Users are 
allocated observing time during which they have 
dedicated usage of the instrument to study particular 
objects. Spacecraft and associated centralised ground 
facilities can be considered to be the "Observatory". 
Operationally, payload control is typically carried out 
by a centralised operating agency, but end users are 
given facilities to control the instrument during their 
allocated slots. Observers are normally at the ground 
observatory facilities during their operational periods. 
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Survey Missions: these carry out repetitive 

observations on a large scale. The spacecraft will 
typically have a single payload instrument, or a 
small number of closely related ones. The spacecraft 
and payload are normally operated by a centralised 
agency on behalf of a number of end users, who can 
request specific observations within the planned 
strategy. 

Multi-Instrument: the spacecraft has a number of (in 
principle) independent experiments, each provided by 
a separate "Principal Investigator" (PI). A centralised 
agency will operate the platform, but Pis are 
responsible for operation of their experiments, using 
services provided by operating agency. Pis can be 
remote from the control centre, submitting requests 
and getting data from their experiments 
electronically. 

Telecommunications Missions: the spacecraft has a 
transponder(or transponders) to provide 
communications between ground stations ("fixed" 
service) or between another spacecraft and 
ground (data relay service). Hie spacecraft and its 
payload is usually operated by a centralised agency 
on behalf of the end users. Allocation of transponder 
communication channels to users (or subscribers) is 
made as a function of service requests. 

The above classification of missions shows the 
common characteristic that missions are usually 
operated by a central agency on behalf of the end 
users. This reflects the fact that there is normally 
only one uplink route for commands and that 
operation of the platform and the payload are often 
interlinked (e.g. through resource dependencies). In 
all cases some sort of mission planning is needed to 
process user requests. 

III. MISSION PLANNING FOR SURVEY 
MISSIONS: ERS-1 

The first European Remote Sensing Satellite (ERS-1) 
was launched in July 1991 by ARIANE-3. The main 
mission of ERS-1 is the monitoring of the state of the 
ocean and ice. It is in a near polar orbit at an 
altitude of c. 800 km. Its main payload is the AMI 
(Active Microwave Instrumentation) which comprises 
a synthetic aperture radar (SAR), a wind 
scatterometer and a radar altimeter. An on-board data 
handling system (IDHS) includes a tape recorder, 
which records data from all instruments except the 
SAR; the tape recorder operations have to be 


scheduled. The SAR can only be operated in ground 
station contact, so that the data acquired can be 
downlinked in real time. 

The prime ground station both for TT&C and 
payload data acquisition is at Salmijaervi near Kiruna, 
Sweden and the control centre (the ERS Mission 
Management and Control Centre - MMCC) is at the 
European Space Operations Centre (ESOC), 
Darmstadt, Germany. Services for end users are 
provided by the ERS-1 Earthnet Central Facility 
(EECF) at ESRIN, Frascati, Italy. 

The ERS Mission Planning System (MPS) is 
responsible for planning (1) spacecraft and payload 
operations and (2) ground station operations, in 
particular data acquisition and data processing 

ERS-1 operates mainly autonomously based upon 
uplinked command schedules covering 24 hours. 
Mission Planning is therefore central to ERS-1 
operations. 

Mission Planning for ERS-1 is split into two parts 

1, Preparation of the Preferred Payload Exploitation 
(PEP) from external user requests. 

2. Preparation of the Detailed Mission Operations 
Plan (DMOP) from which the command schedule file 
uplinked to the spacecraft is generated. 

Step 1 (the user-oriented part) takes place at the ERS- 
1 Earthnet Centre Facility, Step 2 takes place at 
ESOC, the DMOP being produced by the ERS-1 
Mission Planning System (MPS). The DMOP is 
passed to the MMCC for execution. It is also 
transmitted back to EECF for information. A 
restituted DMOP, reflecting the actually executed 
operations, is also sent to EECF. Plans cover 3 days 
and are available at least 24 hours before execution. 

CRITICAL DISCUSSION 

The ERS-1 MPS is the most ambitious and expensive 
mission planning system developed at ESOC. The 
split of responsibility between ESRIN and ESOC is 
in principle sound, with ESRIN collecting and 
filtering user requests and then passing them to the 
MPS at ESOC in a high level form for conversion 
into the final schedule for uplink. 
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The following problems are noted 

Rules and Constraints: the rules and constraints for 
mission planning are specified in a Budgets and 
Constraints Document. The rules have been hard 
coded into the MRS. As a consequence it is not easy 
to make changes in them. Ways of incorporating 
rules and constraints into an early modifiable database 
or knowledge base need to be examined. 

Interface between control centre and user centre; 
Definition of this interface was not done under 
sufficiently rigorous control. This highlights the need 
for preparing a complete Interface Control Document 
under configuration control at a fairly early stage. 
Furthermore, the MMCC/EECF interface does not 
provide sufficient constraints information to allow the 
MPS to complete its work without discussion between 
EECF and ESOC Mission Planning staff. 

Testing: testing of such a complex system is difficult 
and needs considerable user support (i.e. from 
operations personnel). Provision of user-defined test 
procedures for use by developers was found to be 
necessary, as was more formal acceptance tests by 
operational mission planners 

IV. OBSERVATORY MISSIONS: ISO 

The Infrared Solar Observatory (ISO) is planned for 
launch in 1995. It will carry a telescope with four 
focal plane instruments. It will fly in a near 
geosynchronous orbit, which gives, on average, 10 
hour passes over the prime ground station situated at 
Villafranca, near Madrid, Spain. ISO operations are 
carried out in real-time according to a ground- 
executed schedule, i.e. not an on-board schedule like 
ERS-1 (sect. 3.1) or EURECA (sect. 3.3). Only one 
of the four focal plane instruments operates at any 
given time. Observations can vary in length from 2 
minutes to 10 hours. There are no resource 
constraints. 

Mission planning for ISO is split into a user-oriented 
part (MPP1) under the responsibility of ESA's Space 
Science Department and an operations oriented part 
(MPP2) under ESOC responsibility. The mission 
planning concept involves an iteration between these 
parts: Firstly, a Planning Skeleton file (PSF) is 
prepared by MPP2, in which slots are identified for 
payload operations and for platform operations. 
Secondly, MPP1 processes observation requests and 
produces an instrument command schedule to fit in 


the allocated slots. The instrument commands are 
expressed as mnemonics, referring to pre-prepar ed 
binary command sequences. MPP1 transmits this PSF 
to MPP2 as the Planned Observations file (PQF). 
Thfrdly, MPP2 inserts fiight dynamics %g. atdtticle 
adjustment) commands necessary for the instrument 
observations and merges in command requests from 
ESOC operations staff. The result is a Central 
Command Schedule (CCS) for submission to the 
commanding system. 

CRITICAL DISCUSSION 

A number of very positive points about the ISO 
approach are: 

- Use of the PSF technique, allowing platform and 
payload operations to be planned separately. This 
appears to be particularly applicable for missions like 
ISO. 

- A very rigorous approach taken to preparation and 
control of interfaces (via formal Interface Control 
Documents) also resulted in early definition of the 
interfaces and functionality of the ISO Mission 
Planning System, so development of both parts could 
proceed independently. 

Another interesting feature has been the application of 
a rigorous separation between platform and payload, 
the idea being separation of responsibilities for 
platform and payload control the former being that of 
the operations control centre (ESOC) and the latter 
that of the Observatory. This has led to what is in 
effect two control systems constrained by the 
necessity of having one uplinker. These two de facto 
control systems are distributed over a complex 
configuration of computers. This affects both mission 
planning and the on-line control systems. This has 
several consequences 

- End to end testing of the whole mission planning 
and commanding process is made more complex, 
since instrument command execution verification 
occurs within instrument workstations rather than on 
the real-time control system. 

- The split of operational responsibility has led to a 
large number of file transfers between systems. This 
is related to the large amount of hardware associated 
with the different groups. This may have performance 
and reliability impacts. 
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- Instrument commands sequences are prepared by 
MFP2 in unlink form . Input from MPP1 to MPP2 is 
in the form of mnemonics referencing these pre- 
prepared uplink blocks. A command translator 
converts the mnemonics to the uplink form. This is 
cumbersome and could be inflexible and error prone 
if instrument command sequences need to be 
changed. 

3 MULTI-INSTRUMENT MISSIONS: EURECA 

EURECA was launched by the Space Shuttle on 29th 
July 1992 and is planned to be retrieved by the 
Shuttle about April 1993. EURECA carries a 
complement of some 15 experiments, serviced in 
some cases by core (or common) facilities (furnaces 
etc.). The experiments are in the main independent, 
except where they make use of core facilities. A 
number of discipline areas are covered, including 
microgravity (protein crystallisation and materials 
science), solar science, in-orbit data relay and 
spacecraft technology (e.g. a new type of ion 
thruster). EURECA flies in a 28° inclination circular 
low-earth orbit at an altitude of c. 500km. Two 
ground stations at Maspalomas (Canary Islands) mid 
Kourou (French Guiana) are being used during the 
routine phase. Station passes are short (2-10min.) and 
occur in a consecutive set of 4-5 orbits. The contact 
ratio with the ground is thus very low and payload 
operations mostly occur autonomously when the 
spacecraft is out of contact with any ground station. 
This makes planning of payload and platform 
operations essential, especially as the resource 
constraints on EURECA (primarily power, cooling 
and data storage) are such that it is not possible to 
run all experiments in parallel. Thus EURECA 
mission planning is used to schedule operation of the 
experiments such that available resource limits are 
not exceeded. Passes are devoted mainly to uplinking 
of schedules and dumping of data from on-board 
memory. 

EURECA mission planning can be split into two 
parts: pre-launch planning and operational planning. 

Pre-launch planning; This produces a baseline plan 
for the entire mission based on certain assumptions, 
for example the amount of power generated by the 
solar panels, the efficiency of the on-board cooling 
loop and the expected orbit and launch time. The 
baseline plans served to do the following; 


1. Determine that sufficient time could be allocated to 
each experiment to satisfy the requirements of the 
principle investigator. 

2. Provide a basis for the daily planning during the 
actual mission, obviously this could not be exact 
since the real orbit and hence times of events differs 
from that predicated prelaunch. Also the radiators 
appear to be less efficient than predicted (this latter 
providing a benefit in power availably as less heating 
is required to keep the freon loop inside its nominal 
operating temperature range). 

Operational planning; This is carried out daily with 
the aim of generating a list of telecommands for 
uplink to the on-board master schedule for time- 
tagged execution. It takes account of the following: 

- the baseline plan 

- requested changes (from the principle 
investigators) 

- latest orbital event file 

- known spacecraft status (i.e. resource 
availability) 

The EURECA mission planning system provides tools 
which assist both phases. These consist of the 
following: 

1. Operation Definition Editor; this defines the 
resource profiles (power, cooling, data rate etc.) of 
each schedulable operation as a function of time. 

2. Operation Request Editor; this is used to define the 
time constraints which should be applied when 
scheduling the start of an operation. These constraints 
are expressed as windows relative to GMT, orbit 
number, orbital events (eclipse start/end. South 
Atlantic anomaly transits, ground station passes) or 
combinations of these. 

3. Mission Planning Aid (MPA); this is an interactive 
tool, with an X-windows based user interface. The 
operation definitions and requests defined by the 
above editors, along with the orbital event file, are 
used as input to schedule operations. It can be run in 
three basic modes. The first mode is fully interactive, 
in which the user must intervene to resolve any 
clashes found, either by accepting the clash, rejecting 
the operation or moving the start of the operation 
such that there is no longer a resource conflict. The 
other two modes are "semi-interactive" where the 
user can either specify that all operations causing 
clashes be rejected or alternatively be accepted. 
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These last two modes are described as "semi- 
interactive 1 ' because certain conflicts (viz the 
execution of master schedule commands during 
downlink of the onboard memory unit) are considered 
too critical to be handled automatically and so user 
intervention is always required in these cases. 

The above tasks run on VAX workstations in 
complete "stand alone" from the rest of the EURECA 
dedicated control system (EDCS). Once the daily 
planning has been completed a file of commands for 
the desired time period, typically extending 48 hours 
from the end of the next pass sequence, is generated 
and then sent via DECNET to the prime EDCS 
VAX, where it is inserted into the commanding chain 
and later uplinked. 

CRITICAL DISCUSSION 

A principle difference between the EURECA mission 
planning approach and those of ERS-1 and ISO is the 
absence of an explicitly identified user-oriented step, 
despite the quite large number of Pis. The whole 
process takes place at the control centre. Because 
mission planning is done under a single responsibility 
this user-oriented step was not explicitly identified. 

The general principles upon which the EURECA 
Mission Planning Aid is based seem to be sound. 
Much of the planning of the mission is done in 
advance. The bulk of the changes in the schedule 
from day to day, will be due to the shift in the orbital 
event times. Inputs from Pis also influence the daily 
schedules, but have not been, so far, large in volume: 
The mission design, in which prefiltering and 
harmonisation of requests was done pre-launch has 
been borne out in practice. However, such an 
approach would not have been appropriate for a 
mission like ERS-1, in which the influence of user 
requests is much more dynamic and cannot be 
planned in advance to the same extent. 

The MPA detects resource clashes. However, the 
following deficiencies should be noted: 

- it does not give an analysis of the contributions to 
the resource clash; to find this out the user has to 
examine the operations requests, which is not 
straightforward especially since instruments switched 
on considerably earlier than the time of the clash may 
be resource consumers. 

- it does not provide any means to automatically 
resolve resource clashes (as the ERS-1 MPS does). 


This reflects the fact that Pis have not been able to 
specify any algorithm for solving these clashes. 

- it lacks flexibility in applying the scheduling 
constraints. The requirements for these were defined 
well before launch, but in practice it has been found 
that change requests can be difficult to formulate in 
terms of the scheduling rules. 

- The command request interface with the PFs are 
received in a written form. They can be slightly 
"fuzzy", which involves the operations staff in 
considerable interpretation work. 


V, LESSONS LEARNED 

Examination of the critical discussions above, shows 
the following common themes: 

1. Mission planning systems naturally split into two 
parts, the user interfacing part (Phase 1 or MPP1) 
and that producing the operations schedules and 
interfacing to the control system(Phase 2 or MPP2). 
A number of major problems resulted from 
difficulties in the set up and interaction of these two 
parts, particularly when they are under separate 
responsibilities. Problems can be avoided by clear 
formal agreements on separation of tasks, document 
and controlled interface descriptions/agreements. 

2. Mission Planning systems carry out their 
scheduling using a set of rules and constraints. 
Problems result both from late knowledge of these 
rules and from the "hardwiring " of these rules into 
planning systems, making the inevitable changes and 
corrections difficult. 

3. Mission planning systems normally run off-line; as 
a consequence they tend to be tested less thoroughly 
in operations than spacecraft control systems. 
However they are already important operational tools 
and will become more so as missions become more 
complex. Testing of mission planning systems will 
therefore have to be more thoroughly integrated into 
mission test programs. 

4. The discipline of goal-oriented optimisation needs 
more thorough exploration, at least as far as ESA 
Mission Planning systems are concerned. Algorithms 
from the Operations Research disciplines exist to do 
this, but there has been little practical study of their 
application to Mission Planning. 
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5. Projects are being set up in which the division of 
responsibilities (a management matter) assumes that 
platform and payload control can be separated (a 
technical matter). The ISO example is a more or less 
successful attempt to do this, although it does 
illustrate some of the potential pitfalls of this 
approach. 

6. While certain aspects of mission planning are of a 
specialised nature (perhaps mission specific) it is 
possible to identify areas (e.g. scheduling rules) 
where it may be possible to use existing 
commercially available products to reduce the amount 
of customised software. 


VI. GENERIC MISSION PLANNING TOOLS 

Having completed this rather high level review of 
some recent mission planning systems developed at 
ESOC, it is worth noting that all the systems were 
developed independently and use no common 
elements. While it is clear that there are a number of 
essential differences between the missions concerned, 
it is also clear that there are some commonalities. Is 
it possible to identify some common functions which 
could be implemented as reusable tools? An ongoing 
ESA study is examining this problem. To date the 
mission planning approaches discussed here have 
been analyzed in detail, together with a number of 
other approaches from both ESA and NASA. 31 
distinct mission planning functionalities have been 
identified and a commonality matrix established for 
the various missions. Common functions include, 
among other planning request handling, orbit 
propagation, activity scheduling, conflict 
identification and resolution, time-line visualisation 
with zooming, command schedule generation. The 
plan is that a workable concept for generic mission 
planning facilities can be developed and that key 
elements of it can be prototyped and demonstrated in 
application to real missions. This should feed into 
both the ongoing programme of spacecraft control 
infrastructure development (SCOS-II, see Ref. 2) and 
the Advanced Technology Operations Systems 
(ATOS, see Ref. 3), which seeks to develop 
knowledge-based elements to be added to this 
infrastructure. 


1. Mission Planning for an Earth Observation 
Low Earth Orbiter: ERS-1, K Hirst and E 
M Sorensen, 1992, Proceedings of 
SPACEOPS 1992, Pasadena, CA, 

2. SCOS-II: ESA's New Generation of Mission 
Control System, 1992, J F Kaufeler et a!. 
Proceedings of SPACEOPS 1992, Pasadena, 
CA, 

3. The Advanced Technology Operations 
System ATOS, 1992, J F Kaufeler et al. 
Proceedings of SPACEOPS 1992, Pasadena, 
CA. 


224 



